python logging
この記事が良い。早く読みたかった。
loggingは、あるソフトウェアが実行されているときに起こったイベントを追跡するための手段です
Why:
あるイベントを記録したい。その情報をどう記録するか、記録をどう保存・保持するかを簡潔・柔軟に行いたい。
Who:
二人
logger: loggingを実行するインスタンス
handler: 記録するイベントをどう記録媒体(stream, file, mail, cloud)に持っていくかを取り扱う
How:
この二人.
loggerがhandlerを内包する(loggerのメソッド、最終的にはイベントのcallbackみたいな形？）
抱える形なので、loggerはhandlerを複数持てる。
また、プログラム（ランタイム）の中で、複数のloggerインスタンスを持てる。
通常、ファイル(モジュール）ごとに、loggerを持つのが慣習として存在する。
明示的なloggerが見えなくても、root loggerというのがいる。すべてのloggerの親。
木構造になってる。
子供のloggerが出したloggingは、親へpropagateする。（止める設定も、たぶんある)
で、この二人は、どのレベル以上のログを扱うが決められてる。
critical, error, warning, info, debugの5種類。
あと、handlerは、イベントの記録をどういう文体（format)で記録するが決められてる（セットする）
読み物
yamlとかで設定する例がある
レベルとは
CRITICAL(50), ERROR(40), WARNING(30) INFO(20) DEBUG(10) NOTSET(0)
重要度の順にならんでおり、重要なものは出す。どこまで出すかを決定する。
INFOで設定したら、20以上のCRITICAL, ERROR, WARNING, INFOが出力される
自分の関心のあるところは、DEBUGにしておいて、
他のところは、INFOにしておいて
本番は WARNING?以上とする??
handler, loggerなどで、デフォルト？のlevelを持たせておくことができるし、最終的にはloggerのメソッドがレベル別
優先順位は？大元の handler, logger, medhodの順に個別性が強くなり権限強い？
それぞれ、logger, handlerの持つLEVELに合致しないのは出さないようだ。
であれば、consoleにはDEBUG, fileにはINFOみたいなものは、make senseなのか。
print()との違い
print()は、標準出力に問答無用に出す。
loggingは、いろいろカスタマイズできる。 レベル設定、出す場所、フォーマットなど。
環境(開発、テスト、本番)などで、切り替えする
handler(だれが取り扱うか、streamingか、fileか), formatterで出力の形を決めたインスタンスを作って、
そのインスタンスが適宜、重要度とメッセージを決定する。必要に応じてインスタンスを作っておく。
設定:
code: hello_logging.py
import logging
logging.basicConfig(...)
となるのが普通のようだけど、、このconfig を別途設定ファイルにしておきたい。
yamlで書こうとしたら、面倒そうだ。メモ的な項目を入れると errorで蹴られてしまう。
出力形式
jsonで出しておきたい気がする。やりだしたら、きにしなくなるかもだけど、
lightgbmでのlogging
カスタマイズ方法について議論があるのはわかった。それ以上わからず。
callbackがあるが、所定のものだけなので、